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ABSTRACT 


A space  data  relay  network  for  controlling  and  reading-out  military 
satellites  could  provide  better  coverage,  more  capacity  and  better  surviva- 
bility than  the  existing  network  of  ground  relay  stations. 

This  report  compares  two  architectural  schemes  for  a space  data  relay 
network — "centralized"  and  "distributed".  Past  studies  have  concentrated  on 
centralized  architectures  which,  like  NASA's  Tracking  and  Data  Relay  Satellite 
System,  would  have  dedicated  data  relay  satellites  and  large  ground  control 
centers.  Because  military  requirements  are  more  strigent  than  NASA's,  the 
data  relay  satellites  would  need  to  be  significantly  more  capable  than  TDRS. 
High  costs  and  technical  risks  have  therefore  prevented  deployment  of  a 
military  space  data  relay  network. 

As  an  alternative,  this  report  introduces  a distributed  architecture 
in  which  network  assets  are  dispersed  among  user  spacecraft  as  add-on  data 
relay  packages.  The  ground  control  centers  are  likewise  small  and  widely 
dispersed.  The  following  advantages  over  a centralized  architecture  are 
expected . 

• Network  design  less  sensitive  to  user  requirements 

• Phased  growth  rather  than  block  changes 

• Permits  continuing  evolution  of  technology 

• Adaptable  to  mission-specific  or  common-user  deployments 

• More  survivable. 

This  report  presents  two  design  examples  to  illustrate  some  essential 
differences  between  centralized  and  distributed  networks.  First,  a typical 


set  of  user  requirements  is  examined  and  generalized  into  broad  classes  of 


service  in  order  to  decouple  basic  architectural  issues  from  detailed  user 
requirements.  Some  network  implementation  possibilities  are  discussed  and 
expected  advances  in  the  technologies  of  laser  communications,  millimeter 
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1. 


OVERVIEW 


It  has  long  been  recognized  that  the  problems  of  satellite  control  and 

data  read-out  would  be  well  served  by  some  form  of  space  data  relay  network. 

Militarily  we  grow  increasingly  dependent  on  our  space  assets,  and  almost  no 

effort  is  spared  to  make  the  satellites  reliable  and  survivable.  Yet,  like 

3 

other  military  assets,  satellites  rely  on  a supporting  C (command,  control, 

3 

communications)  structure  in  accomplishing  their  missions.  Today  that  C 
structure  is  far  more  vulnerable  to  disruption,  sabotage  or  direct  attack 
than  are  the  satellites  themselves.  It  also  limits  th*>  potential  usefulness 
of  satellites  in  terms  of  the  coverage  and  data  transfer  rates  it  can  provide 

1.1  CENTRALIZED  NETWORKS 

3 

Today  our  space  C structure  is  founded  on  a ground-based  data  relay 
network  (Fig.  1.1).  Commands  and  data  are  relayed  to  and  from  satellites 
via  overseas  tracking  stations.  A network  of  data  relay  satellites  would 
circumvent  many,  if  not  all,  of  the  limitations  of  the  present  approach. 
NASA's  Tracking  and  Data  Relay  Satellite  System  (TDRSS)  (Fig.  1.2)  is  a good 
example.  The  proposition  to  establish  just  such  a network  for  military 
satellites  has  come  up  rep  atedly  for  a decade  or  more.  Upon  consideration, 
the  conclusions  have  always  been:  military  requirements  (Fig.  1.3)  are 
significantly  more  demanding  than  NASA's,  meeting  them  implies  a data  relay 
satellite  that  stretches  the  state-of-the-art  in  several  directions  (Fig. 
1.4),  therefore  the  cost  and  technical  risk  have  been  deemed  not  justifiable. 

Therefore  the  great  majority  of  military  satellites  will  continue  using 
the  ground-based  network  for  the  foreseeable  future.  However,  there  exist  a 
few  special  systems  with  particularly  pressing  needs  for  a space  data  relay 
capability  (Figs.  1.5,  1.6).  These  have  triggered  some  individual,  mission- 
specific  technology  developments.  We  can  expect  other  equally  pressing 
requirements  to  arise  from  time  to  time  in  the  future.  Rather  than  have 
each  new  problem  trigger  another  solution,  it  would  be  better  to  have  a 
common  approach,  i.e.,  an  architectural  plan. 
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MISSION 


ig.  1.1.  The  USAF  Satellite  Control  Facility  (SCF) , a ground-based  data 
elay  network  for  satellite  tracking,  telemetry  and  command  (simplified 
epresentation) . 
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FUNCTION 

DATA  RATE 

CHANNELS 

COMMAND/TELEMETRY  (TTC) 

~200  kbps 

30 

MEDIUM  RATE 

~ 1 0 Mbps 

13 

MISSION  DATA  (MRM) 

HIGH  RATE 

~ 1 Gbps 

4 

MISSION  DATA  (HRM) 

Fig.  1.3.  Estimated  military  space  data  relay  requirements  for  the 
mid-1990 ' s . 
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Recognizing  that  fiscal  considerations  alone  will  preclude  TDRSS-like 

system,  this  report  attempts  to  lay  the  ground  work  for  an  alternate  space 

3 

data  relay  architectural  plan.  It  is  based  on  the  notion  that  the  C network 
for  our  space  resources  can  be  distributed  among  the  satellites  themselves, 
rather  than  being  a separate  and  distinct  entity  such  as  the  SCF  now  is  or  as 
a TDRSS-like  data  relay  network  would  also  be. 

1.2  DISTRIBUTED  NETWORKS 

This  approach  is  called  the  "Distributed  Network"  to  distinguish  it  from 
the  SCF  and  TDRSS,  which  are  classified  as  "Centralized  Networks".  The  Distri- 
buted Network  is  based  on  the  prospect  that  a family  of  standardized  data 
relay  packages  (or  "Standard  Nodes,"  Fig.  1.7)  can  be  developed  to  fly  as 
secondary  payloads  on  a variety  of  high-orbiting  satellites.  These  can  provide 
data  relay  service  to  other  satellites  of  the  same  or  other  missions.  These 
"Standard  Nodes"  would  be  Interoperable  and  have  enough  built-in  flexibility  to 
allow  networking  them  in  different  ways  to  meet  different  situations  as  they 
arise:  new  nodes  are  added,  old  ones  fall,  the  coverage  requirements  change, 
etc.  Such  a network  could  evolve,  beginning  with  high-priority  users  only, 
and  gradually  expanding  until  all  space  resources  are  served.  A significant 
consideration  is  that  the  funding  of  such  a network  could  be  spread  over  many 
years . 

3 

A space  C network  distributed  among  user  satellites  should  be  inherently 
more  survivable  than  a network  structured  around  large,  dedicated  data  relay 
satellites.  An  equally  important  consideration  is  the  survivability  of  mission 
ground  segments.  Each  mission  has,  in  addition  to  its  satellites,  one  or  more 
ground  control  centers  or  data  processing  centers.  Presently,  these  centers 
are  mostly  clustered  in  one  location  (at  the  site  of  the  master  control  station 
of  the  ground-based  network).  The  distributed  network  considered  here  would 
allow  these  ground  assets  to  be  completely  dispersed  (even  transportable), 
further  enhancing  overall  mission  survivability.  Figure  1.8  summarizes  the 
points  of  comparison  between  the  distributed  and  centralized  networks.  These 
points  are  expanded  upon  in  the  following  sections. 
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CENTRALIZED 

DISTRIBUTED 

SPACE  SEGMENT 

DATA  RELAY 

PACKAGES  ON  HOST 

SATELLITES 

SATELLITES 

GROUND  SEGMENT 

SEVERAL  LARGE 

COMPLETELY  DISTRIBUTED 

NODES 

GROWTH/TRANSITION 

BLOCK  CHANGES 

EVOLUTIONARY 

INITIAL  COSTS 

HIGH 

LOW 

ULTIMATE  COSTS 

HIGH 

PROBABLY  HIGHER 

SURVIVABLE 

LESS 

MORE 

FLEXIBILITY 

SENSITIVE  TO 

ADAPTABLE  TO  CHANGING 

INITIAL  REQUIREMENTS 

REQUIREMENTS 

Fig.  1.8.  Comparing  the  characteristics  of  centralized  and  distributed 
space  data  relay  networks. 


1.3  REPORT  SUMMARY 


Section  2 discusses  the  background  of  the  space  C problem  and  defines  the 
terms  used  in  the  remainder  of  the  report.  Section  3 addresses  requirements. 

It  establishes  a methodology  by  which  a mass  of  detailed  user  requirements 
can  be  turned  into  an  overall  network  specification.  This  report  addresses  a 
particular  set  of  user  requirements  taken  from  a recent  study  sponsored  by  the 
ASFC  Space  Division  (Reference  1),  however  the  methods  should  apply  to  other 
reasonable  sets  of  requirements.  Section  4 explores  a centralized  network 
architecture,  which  satisfies  the  example  network  requirements,  and  summarizes 
its  characteristics.  Section  5 then  explores  the  alternative — a distributed 
network.  An  example  of  such  a network  is  presented  and  its  characteristics 
are  compared  with  the  centralized  network.  Sections  4 and  5 stress  architec- 
tural issues.  Technology  issues  are  addressed  in  Section  6.  With  the 
continuing  maturing  of  laser  communications  technology,  it  appears  that  a 
distributed  space  data  relay  network  will  be  a technically  viable  way  to 
fulfill  our  future  military  space  data  relay  needs.  Political  and  management 
issues,  which  often  play  a more  important  role  than  technology  in  how  future 
military  systems  evolve,  are  outside  the  scope  of  this  report. 


2 . BACKGROUND 

Space  resources  have  become  integral  parts  of  our  military  force  structure 

3 

and,  like  any  other  military  force,  need  a supporting  C (command,  control  and 

communications)  structure  to  be  effective.  A data  relay  network  is  an  impor- 

3 

tant  element  of  the  space  C structure.  This  section  describes  the  nature 

3 

of  the  space  C problem,  the  functions  of  a data  relay  network,  and  defines 
the  terms  used  in  the  remainder  of  the  report. 

2.1  A SPACE  MISSION 

The  basic  organizational  unit  of  our  space  forces  is  the  "mission"  (or 
program).  The  elements  of  a typical  mission  are  shown  in  Fig.  2.1.  There 
are  usually  several  mission  spacecraft  (MSC)  per  mission.  These  are  divided 
functionally  into  "payload"  and  "bus"  (or  housekeeping)  parts.  The  mission 
control  center  (MCC)  on  the  ground  includes  both  bus  and  payload  control 
functions.  These  functional  parts  may  be  located  together  or  separately. 

There  may  be  several  separate  MCCs  for  redundancy. 

There  are  three  types  of  communications  channel  required  between  MSC  and 
MCCs:  mission  data,  telemetry  and  command.  The  latter  two  are  commonly 
called  TTC  (telemetry,  tracking  and  command).  Mission  data  rates  are  typically 
much  higher  than  TTC  rates.  Relatively  few  missions  need  mission  data  channels. 

Although  not  indicated  in  Fig.  2.1,  mission  data  or  TTC  channels  may  be 
"point-to-multi-point"  channels  to  allow  more  than  one  MCC  site  to  read  out  a 
MSC  at  one  time.  These  channels  may  be  time-continuous  for  some  missions, 
although  intermittent  channels,  which  allow  scheduled  contacts  with  MSC,  are 
sufficient  for  most  missions. 

2.2  SPACE  C3  ARCHITECTURE 

Since  there  are  many  missions,  each  with  several  MSC  and  MCCs,  an  overall 
3 

C architecture  for  space  may  be  represented  as  in  Fig.  2.2.  The  role  of  the 
"data  relay  network"  is  to  provide  the  mission  data  and  TTC  channels  between 
MSC  and  MCCs.  Although  there  may  exist  several  distinct  sub-networks,  the 
term  "data  relay  network"  as  used  here  encompasses  the  total  problem  (all 
channels  for  all  missions). 
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Fig.  2.1.  Elements  of  a typical  space  mission. 
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The  other  channels  in  Fig.  2.2,  i.e.,  those  between  MCCs  and  users  and 
SPADOC  (Space  Defense  Operations  Center)  are  not  specifically  addressed  in 
this  report. 

Without  regard  to  how  the  data  relay  network  is  implemented,  the  charac- 
teristics listed  in  Table  2.1  would  be  highly  desirable  and  are  used  here  as 
a basis  for  comparing  different  network  architectures. 

2.3  DATA  RELAY  NETWORKS 

As  an  example  of  an  actual  data  relay  network.  Fig.  2.3  shows  the  USAF 
Satellite  Control  Facility  (simplified  representation),  which  is  a ground- 
based  network.  It  is  presently  providing  TTC  service  to  virtually  all  mili- 
tary space  missions.  (Mission  data,  where  required,  is  handled  by  dedicated, 
special  purpose  channels.)  MSC  carry  standardized  TTC  packages  for  access  to 
the  network. 

In  comparison  with  the  desired  characteristics  in  Table  2.1,  the  SCF  has 
the  following  limitations. 

Survivability: 

Tracking  stations  on  foreign  soil 

Geographic  centralization  of  MCCs. 

Responsiveness: 

Limited  visibility  of  low  orbits  prevents  continuous  MSC  coverage. 

Flexibility: 

Terrestrial  links  cannot  handle  anticipated  mission  data  rates. 

Most  of  these  limitations  could  be  overcome  by  a network  of  data  relay  satel- 
lites (a  space-based  network)  as  shown  conceptually  in  Fig.  2.4.  Some  points 
of  comparison  of  ground  and  space-based  data  relay  networks  are  listed  in 
Table  2.2.  Figure  2.4  is  representative  of  what  will  be  called  a "centralized" 
space  data  relay  network  in  this  report.  In  spite  of  its  obvious  advantages 
over  the  ground-based  approach  and  the  fact  that  NASA  has  adopted  such  a net- 
work, it  has  some  drawbacks  in  a military  context.  These  will  be  explored 
later  in  this  report  and  an  alternative  will  be  suggested. 
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TABLE  2.1 

DESIRABLE  CHARACTERISTICS  OF  A DATA  RELAY  NETWORK 

1.  SURVIVABLE/ ENDURING 

• Physical: 

Network  as  survivable  as  the  MSC  it  supports. 

Permits  geographic  dispersal  of  MCCs. 

• Electronic: 

Immune  to  jamming. 

2.  RESPONSIVE 

• Permits  Instantaneous  MCC/MSC  Contact. 

(Example:  ASAT  attack  on  one  mission  detected  by 

another.  Warning  must  be  relayed  to  target 
MSC  via  MCCs  in  near-real  time.) 

3.  FLEXIBLE 

• Changing  Requirements: 

Can  accommodate  to  unforeseen  requirements. 

• Changing  Technology: 

Can  phase-in  new  technology. 

4.  AFFORDABLE 

• Initial  Cost. 

• Incremental  Growth  Cost. 

• Total  or  Ultimate  Cost. 

• Operating  Costs. 
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TABLE  2.2 


COMPARISON  OF  SPACE-BASED 
WITH  GROUND-BASED  DATA  RELAY  NETWORKS 
(Assume  Synch-Orbit  Nodes) 

• Better  Coverage  of  Low  Orbits 

Responsiveness  - Real-Time  Connectivity 
Survivability  - Alternate  Paths 

• Overseas  Sites  Not  Required 

Survivability 

• Allows  Distributed  Ground  Segment 

Survivability  - Dispersal 
Responsiveness  - MCC  Near  Users 

• Allows  Line-of-Sight  Connectivity  Among  Nodes 

Survivability  - Alternate  Paths 
Adaptability  - Reconfiguration 

• Anti-Jam  Considerations 

Ground-Based  Jammers  in  Main  Beams 
Restricts  Frequency  Choices 

• Greater  Impact  on  Mission  Spacecraft 

Greater  Access  Link  Range  (Typically) 

Smaller  Network  EIRP  and  G/T  available,  therefore 
Larger  MSC  EIRP  and  G/T  required 
Narrow  Beams 
Pointing  and  Tracking 
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2.4  NETWORK  TERMINOLOGY 


Some  definitions  are  needed  to  expedite  the  following  discussions.  We 
distinguish  here  between  the  external  and  Internal  descriptions  of  a network. 
The  external  description  of  a network  can  be  considered  as  a functional 
specification  for  the  network  and  the  internal  description  as  the  particular 
realization  by  which  the  specification  is  fulfilled. 

External  Description:  The  network  is  viewed  as  a "system"  (black  box) 
completely  described  by  its  inputs  and  outputs  as  shown  in  Fig.  2.5. 

1.  Access  Port:  Network  input  port.  The  predominant  data  flow  is 
from  MSC  to  MCC;  therefore  "input  port"  refers  to  the  MSC/network 
Interface  port.  In  Fig.  2.3  the  tracking  station  antenna  is 

the  access  port.  In  Fig.  2.4  it  is  the  data  relay  satellite 
antenna. 

2.  Access  Link:  MSC-to-network  connection.  It  would  be  a downlink 
in  Fig.  2.3  or  a crosslink  in  Fig.  2.4. 

3.  Exit  Port:  Network/MCC  interface  point. 

4.  Channel:  A communications  path  through  the  network.  Point- 
to-mult 1-point  channels  as  shown  in  Fig.  2.5  are  allowed. 

5.  Contact:  An  interval  of  MSC/MCC  communication. 

6.  Network  Control:  Includes  all  functions  required  to  establish 
contacts  such  as  channel  switching,  spatial  acquisition  of  the 
access  link,  etc. 

Internal  Description:  Internally  the  network  is  described  by  a topologi- 
cal diagram  (as  in  Fig.  2.6)  consisting  of  nodes  connected  by  links. 

7.  Link:  A communications  medium  (microwave,  cable,  etc.)  capable 
of  carrying  one  or  more  channels.  A link  may  be  an  access  link, 
exit  link  or  trunk  link  as  in  Fig.  2.6(a).  Trunk  links  are 
those  which  do  not  cross  the  network  boundary. 

8.  Node:  An  Intersection  of  two  or  more  links.  A channel  switching 
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capability  is  implied.  Nodes  can  be  access  nodes,  exit  nodes  or 
internal  nodes  as  in  Fig.  2.6(a). 

9.  Central  Node:  A node  through  which  all  channels  pass.  There 
may  be  more  than  one  central  node  per  network. 

2.5  CENTRALIZED  AND  DISTRIBUTED  NETWORKS 

Given  a desired  set  of  network  input/output  characteristics  (a  functional 
specification),  the  topology  by  whisji  the  network  is  realized  can  range  from 
totally  centralized  (Fig.  2.7(a))  to  totally  distributed  (Fig.  2.7(b)). 
Historically,  communications  networks  have  tended  toward  a centralized  topology, 
the  incentive  being  to  minimize  transmission  cost  per  circuit-mile  by  multi- 
plexing many  circuits  together  into  large  trunk  links.  Generally,  one  10  Mbps 
link  is  less  expensive  than  ten  1 Mbps  links.  This  approach  leads  to  a topo- 
logy with  a minimum  number  of  nodes  similar  to  Fig.  2.7(a). 

At  the  other  extreme,  in  a totally  distributed  network,  all  user  terminals 
would  become  network  nodes,  interconnected  by  direct  links  carrying  one  or  a 
few  channels  each.  Fig.  2.7  illustrates  two  important  features  of  the  distri- 
buted network  relative  to  the  centralized  one.  First,  data  may  flow  across 
mission  boundaries.  In  the  example  a spacecraft  of  mission  B is  shown  relaying 
data  from  a mission  A spacecraft.  Second,  the  network  control  strategy  is 
inherently  more  complex  in  a totally  distributed  network.  The  trunk  configura- 
tion must  be  dynamic  to  accommodate  MSC  motion,  whereas  in  the  centralized 
network  MSC  motion  is  readily  accommodated  by  dynamic  access  links.  The  nodes 
and  trunks  remain  static. 

In  spite  of  these  apparent  disadvantages,  a distributed  space  data  relay 
network  may  offer  some  advantages  in  a military  context  in  terms  of  greater 
survivability,  lower  incremental  costs,  and  an  easier  evolution  or  transition 
from  current  practices.  Later  we  will  examine  a distributed  network  topology 
that  lies  between  the  two  extremes  of  Fig.  2.7  and  incorporates  some  of  the 
advantages  of  both. 


2.6  NETWORK  ORGANIZATION  AND  EFFICIENCY 


A network  can  be  organized  as  a single,  multi-mission  network  or  as  a 
number  of  mission-specific  sub-networks  as  shown  in  Fig.  2.8.  In  the  first 
case  (shared),  all  access  ports  are  shared  among  all  using  MSC.  Any  MSC  can 
address  any  port.  In  the  second  case  access  ports  and  exit  ports  are  assigned 
to  specific  missions.  A significant  difference  is  that  in  a shared  network 
every  exit  port  must  be  able  to  connect  to  every  access  port.  In  a mission- 
specific  network,  exit  ports  need  only  connect  to  access  ports  of  the  same 
mission.  This  distinction  bears  on  the  total  number  of  trunk  links  required 
and  thus  on  the  cost  of  the  network.  It  will  be  a significant  consideration 
in  the  case  of  a distributed  ground  segment  (many  widely  separated  MCCs). 

Another  significant  difference  is  that  a shared  network  may  need  fewer 
access  ports.  This  is  true  when  it  serves  a large  population  of  low  duty-cycle 
user  spacecraft.  Consider  an  example  where  there  are  10  missions  with  10  MSC 
each  and  all  MSC  require  a 20  percent  contact  duty  cycle.  The  average  total 
data  rate  is  20  channels;  however,  to  allow  for  traffic  peaks  the  network  must 
have  more  than  20  access  ports.  For  example,  99%  availability  (3o  peaks) 
could  be  provided  by  a shared  network  with  32  ports  (see  below).  If  each 
mission  had  its  own  network,  a total  of  60  access  ports  would  be  needed  to 
give  equivalent  service.  Therefore  network  sharing  effects  a 50  percent 
savings  in  installed  capacity.  At  the  other  extreme,  if  the  user  MSC  are 
high  duty  cycle  (say  100%),  then  100  ports  are  needed  in  either  case. 

Generally  speaking,  therefore,  a shared  network  for  low  duty  cycle  users 
will  have  higher  efficiency,  (therefore  lower  cost)  than  mission-specific 
networks.  For  high  duty-cycle  users,  there  is  no  efficiency  advantage  in 
sharing  and  mission-specific  networks  may  in  fact  be  cheaper  because  of  the 
smaller  number  of  downlinks,  particularly  when  multiple  distributed  MCCs 
are  required. 

The  aoove  example  makes  the  simplifying  assumption  of  Poisson  statistics 
for  network  traffic.  Under  this  assumption  the  contact  duty  cycle  is  inter- 
preted as  the  probability,  p,  that  a particular  MSC  is  communicating  at  a 
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particular  time.  The  mean  total  data  rate  is  Np,  where  N is  the  number  of 
MSC.  The  standard  deviation  of  the  total  data  rate  is  a = v^p(l-p).  For 
p = 0.2  and  N = 100,  Np  = 20  channels,  3o  = 12  channels,  and  the  network 
therefore  requires  32  channels  (or  access  ports)  to  accommodate  3o  traffic 
peaks. 
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3.  NETWORK  REQUIREMENTS 

In  the  last  chapter  we  distinguished  between  external  and  internal  network 
descriptions.  To  proceed  we  now  want  to  adopt  a realistic  set  of  specifications 
(i.e.,  an  external  description)  for  a space  data  relay  network.  Then,  in  the 
next  two  sections,  we  will  examine  two  different  internal  realizations  (topo- 
logies) based  on  the  centralized  and  distributed  approaches  defined  in  Section 
2.5. 

Concerning  the  baseline  "specs"  or  requirements  we  will  be  using  for  this 
discussion,  they  are  projected  at  least  10  years  into  the  future  (a  typical 
space  program  gestation  period).  Although  based  on  the  best  information  avail- 
able, they  are  fuzzy  at  best,  and  conclusions  that  depend  strongly  on  them  would 
be  suspect.  This  is  why  "flexibility"  was  identified  as  a desirable  trait  in 
Table  2.1.  We  are  seeking  a network  realization  that  depends  as  little  as 
possible  on  initial  assumptions  about  requirements. 

3.1  THE  SCF  MISSION  MODEL 

The  input  data  for  this  study  are  provided  by  Table  3.1  (Ref.  1).  Of 
several  requirements  models  presented  in  the  referenced  study,  this  one  was 
most  nearly  geared  to  the  mid  1990s. 

The  mission  model  lists  the  missions  expected  to  be  on-line,  the  number 
of  MSC  for  each,  TTC  and  mission  data  rates,  the  number  and  length  of  contacts 
per  day,  priority  and  MSC  orbits.  The  column  labeled  "Mission  Data  Entry 
Regions  in  CONUS"  specifies  the  number  and  location  of  MCCs  (for  some  missions). 
This  mission  model  assumes  five  large  ground  stations,  each  serving  a separate 
CONUS  region. 

3.2  CLASSIFICATION  OF  USER  REQUIREMENTS 

What  is  needed  at  this  point  is  a systematic  method  for  extracting  an 
appropriate  set  of  network  specifications  from  the  detailed  mission  model  in- 
formation. A network  specification  is  an  "external"  description;  i.e.,  the 
number  and  location  of  access  ports  and  exit  ports. 


The  first  step  in  this  direction  is  to  eliminate  unnecessary  detail  by 
classifying  the  information  in  Table  3.1  by  mission  into  a few  broad  categories 
as  follows. 

1.  Channel  class:  data  rates  are  divided  into  three  broad 
categories.  Each  will  correspond  to  a different  access 
port  implementation. 

2.  Space  coverage:  this  refers  to  the  spatial  distribution 
of  access  ports.  Space  coverage  is  determined  by  a combi- 
nation of  MSC  orbit  and  contact  requirements. 

3.  Capacity:  the  number  of  channels  (access  ports)  of  each 
type  is  determined  by  the  number  of  MSC  and  their  contact 
duty  cycle. 

4.  Ground  coverage:  this  specifies  the  number  and  location  of  exit 
ports  and  is  determined  by  the  desired  MCC  locations  for  each 
mission. 

The  following  sections  describe  each  of  these  categories  in  more  detail. 

3.3  CHANNEL  CLASSES 

The  data  rates  in  Table  3.1  are  grouped  into  three  broad  categories,  each 
with  a designation  and  nominal  data  rate  as  shown  in  Table  3.2.  It  is  expected 
that  these  channel  classes  will  reflect  natural  technology  breakpoints;  that 
is,  each  class  will  be  realized  by  a different  technique.  (See  Section  6). 

For  the  later  architectural  discussions,  all  channel  types  have  been  defined 
as  including  a 10  kbps  "forward"  path  (MCC  to  MSC)  for  spacecraft  command  and 
order-wire  purposes. 

3 4 SPACE  COVERAGE 

This  refers  to  the  spatial  distribution  of  access  ports  required  by  a 
mission.  It  is  determined  by  MSC  orbit  and  contact  duration.  The  access  ports 
are  attached  to  access  nodes.  There  can  be  any  number  of  access  nodes  in  a 
network,  but  since  three  is  the  minimum  number  that  can  provide  total  coverage 
of  all  earth  orbits,  we  will  classify  the  space  coverage  requirement  of  a 
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TABLE  3.2 
CHANNEL  CLASSES 


Designation 

Forward  Data  Rate 

Return  Data  Rate 

TTC  (Telemetry, 
Tracking  & Command) 

~ 10  kbps 

~ 200  kbps 

MRM  (Medium  Rate 
Mission  Data) 

~ 10  kbps 

~ 10  Mbps 

HRM  (High  Rate 

Mission  Data) 

- 10  kbps 

- 1 Gbps 

mission  as  1-Node,  2-Node  or  3-Node.  For  this  study  we  will  assume  synchronous- 
orbit  access  nodes.  (The  conclusions  of  this  study  can  be  extended  to  non- 
synchronous  cases). 

3.4.1.  ORBIT  CLASSES 

To  proceed,  three  orbit  classes  are  defined:  low,  high  non-synch,  and 
synch.  The  distinctions  between  them  are  illustrated  in  Fig.  3.1.  Assuming 
three  access  nodes  separated  by  120°,  the  regions  of  single-node  visibility 
extend  to  approximately  2000  nautical  miles  altitude.  Orbits  passing  through 
them  are  defined  as  "low".  "High  non-synch"  orbits  are  those  which  pass 
through  2-node  visibility  regions.  A "synch  orbit"  MSC  may  lie  in  either  a 
2-node  or  a 3-Node  visibility  region. 

3.4.2.  CONTACT  CLASSIFICATION 

The  contact  durations  in  the  mission  model  can  be  classified  as  either 
"intermittent"  or  "continuous".  An  intermittent  contact  is  one  that  can  be 
completed  via  a single  access  node.  For  example,  a low-orbit  MSC  has  an  orbit 
period  of  about  90  minutes.  It  is  in  view  of  a particular  node  for  about  50 
minutes.  A required  contact  duration  of  less  than  50  minutes  would  therefore 
be  classified  as  intermittent.  An  intermittent  contact  requirement  implies 
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the  need  for  only  one  access  port  per  channel.  On  the  other  hand,  a continuous 
contact  requirement,  in  the  case  of  low-orbit  MSC,  implies  that  three  access 
ports  are  needed  per  channel.  (The  two  unused  ports  can  be  utilized  for  other 
purposes  in  a shared  network,  as  we  shall  see.) 

The  orbit  class  and  the  contact  requirement  together  determine  the  space 
coverage  requirement  as  shown  in  Table  3.3.  Again,  this  is  a way  of  specifying 
the  minimum  acceptable  number  of  nodes.  A network  can  have  more  than  three 
nodes  and  still  be  classified  as  either  a 1,  2 or  3-Node  network  according  to 
the  coverage  of  mission  spacecraft  it  provides. 

3.5  CAPACITY 

Capacity  refers  to  the  total  number  of  network  channels  required.  This 
in  turn  determines  the  number  of  access  ports  required.  Table  3. A shows  how 
capacity  is  estimated  from  the  mission  model  data.  For  example,  mission  S-13 
has  3 MSC.  It  requires  6 TTC  and  6 MRM  contacts,  of  0.8  hour  each,  per  day 
per  MSC.  The  MSC  contact  duty  cycle  is  therefore  20  percent.  The  average  data 
rate  per  MSC  is  equivalent  to  0.2  TTC  channels  plus  0.2  MRM  channels.  The 
mission  average  data  rate  is  0.6  channels  each,  therefore  S-13  is  allocated 
1 channel  of  each  type  in  the  network  capacity  determination. 

This  method  of  estimating  capacity  is  adequate  for  the  purposes  of  this 
study.  An  actual  network  design  would  entail  a detailed  statistical  analysis 
to  determine  the  number  of  channels  required.  As  described  in  Section  2.6, 
economies  can  often  be  realized  by  sharing  a network  among  as  many  users  as 
possible . 

From  Table  3.4,  the  required  total  capacity  is  45  TTC,  13  MRM  and  4 HRM 
channels.  This  study  will  assume  that  telemetry  data  are  submultiplexed  onto 
MRM  and  HRM  channels  wherever  possible  as  shown  in  Fig.  3.2.  The  MRM  and  HRM 
missions  would  still  have  access  to  the  TTC  network  for  backup  and  initial 
acquisition,  but  routine  TTC  traffic  would  be  off-loaded  from  the  TTC  net.  By 
this  assumption,  the  TTC  capacity  is  reduced  from  45  to  30  channels  as  shown 
in  the  "Residual  TTC"  line  of  Table  3.4. 
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TABLE  3.3 


SPACE  COVERAGE  REQUIREMENT  AS  DETERMINED  BY 
ORBIT  CLASS  AND  CONTACT  REQUIREMENT 


In  Table  3.4  missions  S-5  and  S-7  are  peculiar  in  that  each  requires 
4 TTC  channels,  but  only  1 MRM  channel.  This  may  be  an  error  in  the  mission 
model,  but  it  will  not  affect  our  conclusions. 

The  number  of  access  ports  is  closely  related  to,  but  not  necessarily 
equal  to,  the  capacity.  For  example,  Figure  3.3(a)  shows  two  mission-specific 
networks.  Mission  B has  a 1-channel,  3-Node  requirement  (continuous  contact 
to  a low-orbit  MSC).  This  leaves  unused  access  ports  which  could  satisfy 
mission  A's  requirement  in  a shared  network  as  in  Fig.  3.3(b).  In  the  latter 
case  the  access  ports  are  fully  utilized;  however,  mission  A must  now  tolerate 
periodic  channel  interruptions  as  the  mission  B channel  is  handed  over  from 
node  to  node.  There  is  obviously  a tradeoff  between  efficiency  and  network 
control  complexity  in  a shared  network. 

3.6  GROUND  COVERAGE 

This  refers  to  the  number  and  distribution  of  exit  ports.  Ground  coverage 
requirements  affect  the  number  and  distribution  of  space  nodes,  the  number  of 
cross  orbit  trunks  needed  and  the  number  of  downlink  trunks. 

Four  classes  of  ground  coverage  are  defined  as  shown  below  and  in  Fig.  3.4. 

1.  Overlap  Coverage:  All  exit  ports  (KCCs)  lie  within  the 
mutual  visibility  region  of  two  synchronous-orbit  nodes 
(Fig.  3.4(a)). 
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DETERMINATION  OF  REQUIRED  NETWORK  CAPACITY 
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Fig.  3.2.  Network  capacity  requirements  and  sub-multiplexing  of  telemetry  data 
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Fig.  3.3.  Advantage  of  a shared  network  for  3-Node  space  coverage. 
The  B Channel  commutates  among  three  acess  ports. 


2.  1-Node:  The  exit  nodes  extend  over  the  entire  visibility 
region  of  a synch-orbit  node  (Fig.  3.4(b)). 

3.  2-Node:  Even  more  widely  distributed  exit  ports. 

4.  3-Node:  Worldwide  ground  coverage  (Fig.  3.4(c)). 

In  Fig.  3.4  note  the  trade-off  between  extended  ground  coverage  and  the  number 
of  cross-orbit  trunk  links  required. 

The  mission  model  used  here  gives  little  guidance  on  ground  coverage 
requirements.  It  appears  to  assume  that  all  MCCs  are  within  CONUS,  which 
corresponds  to  "overlap"  ground  coverage. 

3.7  EXAMPLE  NETWORK  REQUIREMENT 

By  the  above  procedure  the  mission  model  data  in  Table  3.1  can  be  com- 
pressed into  the  network  specification  shown  in  Table  3.5.  This  will  now  be 
used  as  a baseline  to  compare  two  different  network  realizations  (centralized 
and  distributed).  Again,  these  "requirements"  represent  the  most  realistic 
estimates  available  at  the  present  time.  However,  they  should  not  be  consid- 
ered firm  or  fixed. 


4. 


NETWORK  REALIZATION — CENTRALIZED 


The  last  section  addressed  the  specification,  or  external  description,  of 
a space  data  relay  network.  The  SCF  mission  model  was  used  to  derive  an 
example  set  of  specifications  based  on  a realistic  projection  of  USAF  needs. 

This  section  addresses  network  realization;  in  this  case  by  the  centralized 
approach.  Generally  speaking,  the  centralized  approach  (Section  2.5)  seeks  to 
multiplex  individual  channels  into  high-rate  trunks  to  achieve  economical 
transmission  and  results  in  a minimum  number  of  nodes.  This  section  covers 
only  the  topological  aspects  of  network  realization.  The  technology  issues 
are  discussed  in  Section  6. 

4.1  NASA  TRACKING  AND  DATA  RELAY  SATELLITE  SYSTEM  (TDRSS) 

The  TDRSS  is  a good  example  of  a space  data  relay  network  that  follows  the 
centralized  design  philosophy.  NASA  presently  operates  a ground-based  network, 
the  Space  Flight  Tracking  and  Data  Network  (STDN),  similar  to  the  SCF.  TDRSS 
is  considered  a cost  effective  alternative  in  that  it  will  supplant  most  of 
the  STDN  stations  while  providing  the  higher  data  rates  and  extended  coverage 
required  by  the  Shuttle  and  other  new  NASA  missions.  The  TDRSS  System  confi- 
guration is  shown  in  Fig.  4.1  and  the  TDRSS  Satellite  in  Fig.  4.2.  A Lincoln 
Laboratory  review  recently  assessed  the  suitability  of  the  TDRSS  for  typical 
Air  Force  requirements.  Aside  from  the  lack  of  nuclear  hardness  and  anti-jam 
capability,  a significant  mismatch  between  TDRSS  capability  and  USAF  needs 
was  found,  as  summarized  in  Fig.  4.3. 

4.2  A CENTRALIZED  NETWORK  FOR  USAF  REQUIREMENTS 

The  consideration  of  TDRSS  raises  an  issue.  Given  the  type  of  military 
requirements  represented  in  Table  3.5,  is  a centralized  network  similar  to  TDRSS 
a viable  alternative  for  the  Air  Force?  To  pursue  this  question,  consider 
Figure  4.4  which  shows  the  topology  of  one  centralized  network  that  would 
satisfy  the  requirements  in  Table  3.5  Since  we  cannot  consider  all  possible 
variations,  Figure  4.4  attempts  to  epitomize  the  whole  class  of  centralized 
networks  in  that  it  has  the  minimum  possible  number  of  nodes  and  trunks  con- 
sistent with  the  requirements. 
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Fig.  4.2.  NASA  Tracking  and  Data  Relay  Satellite.  Produced  by  TRW 
under  contract  to  Western  Union  Space  Communications  Inc.  for  leased 
service  to  NASA. 
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REASONS  FOR  TDRSS/SCF  MISMATCH 

• DATA  RATE  OF  RETURN  LINK  MA  CHANNELS  DOES  NOT  ACCOMMODATE 
MAJORITY  OF  MILITARY  USERS 

• NUMBER  OF  FORWARD  LINKS  IS  DEFICIENT 


NASA 

SCF 

20  - 40  USERS 

LOW  EARTH  ORBITS 

MOSTLY  LOW  RATE  DATA 

65  - 100  USERS 

VARIOUS  ORBITS 

MOSTLY  MEDIUM/HIGH 

RATE  DATA 

■ — ■■■■■-  , 

Fig.  4.3.  Summary  of  TDRSS  capabilities  compared  to  SCF  "baseline" 
mission  model  (more  modest  version  of  Table  3-1). 
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STATED  REQUIREMENT: 

30  TTC,  13  MRM,  4 HRM 
3 NODE  SPACE  COVERAGE  FOR  TTC  AND  MRM 
2 NODE  SPACE  COVERAGE  FOR  HRM 
OVERLAP  GROUND  COVERAGE  (CONUS  Only) 


" 10  TTC 
5 MRM 
2 HRM 


ACCESS ) 
LINKS  ) 


10  TTC 
5 MRM 
2 HRM 


10  TTC 


l 3 MRM 


MINIMUM  NUMBER  OF  NODES 
MINIMUM  NUMBER  OF  TRUNK  LINKS 
MANY  ACCESS  PORTS  PER  NODE 
HIGH  CAPACITY  NODES  AND  TRUNKS 


Fig.  4.4.  A centralized  space  data  relay  network  that  would  satisfy 
the  example  network  requirements  of  Table  3.5. 
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Figure  4.4  was  derived  from  Table  3.5  as  follows. 

Access  Nodes:  Because  the  mission  model  includes  some  missions  that  need 
"3-Node"  space  coverage  (Table  3.4),  three,  equally  spaced  synchronous  nodes 
are  required.  Nodes  1 and  2 are  CONUS  viewing.  Node  3 ("blind  side")  is 
reached  via  a cross-orbit  trunk. 

Access  Ports:  The  following  considerations  apply  in  allocating  access 
ports  to  the  3 nodes.  The  network  is  a shared  network  for  maximum  efficiency; 
therefore  the  number  of  ports  needed  is  the  same  as  the  number  of  channels 
(Sec.  3.5).  The  distribution  of  ports  is  arbitrary  except  that  Node  3 must 
satisfy  the  "3-Node"  requirement  in  Table  3.5  (9  TTC,  3 MRM).  This  distribu- 
tion was  chosen  because  it  minimizes  the  cross-orbit  trunk  capacity.  Note 
that  "10  TTC"  represents  10  separate  crosslinks.  There  is  a total  of  18  cross- 
links terminating  on  Node  2,  for  example. 

Exit  Ports:  Consistent  with  the  mission  model,  nodes  4 through  8 repre- 
sent five  exit  nodes  serving  five  CONUS  regions. 

Trunk  Links:  At  each  access  node  the  trunk  capacity  must  match  the  total 
access  port  capacity.  For  example,  the  cross  orbit  trunk  (32  Mbps)  accommodates 
the  10  TTC  ports  (200  kbps  each)  and  3 MRM  ports  (10  Mbps  each)  on  Node  3.  In 
a shared  network  all  access  ports  must  be  capable  of  connecting  to  all  exit 
ports  of  the  same  channel  class  (section  2.6).  This  requirement  is  satisfied 
in  Fig.  4.4  by  making  all  downlink  trunks  approximately  2 Gbps  in  capacity  to 
accommodate  multiplexing  of  the  HRM,  MRM  and  TTC  channels. 

As  another  example  of  a centralized  network,  Figure  4.5  shows  a network 
topology  suggested  during  a recent  USAF  Space  Division  study  (Ref.  1).  This 
network  has  a slightly  different  mix  of  channel  types  and  has  four  rather  than 
three  access  nodes,  but  otherwise  is  quite  similar  to  the  canonical  centralized 
network  model  of  Fig.  4.4.  This  example  is  especially  useful  because  it  is 
accompanied  by  satellite  design  studies  that  give  a flavor  of  physical  reality 
to  the  topological  description.  The  proposed  data  relay  satellite  is  shown 
in  Fig.  4.6.  It  is  representative  of  the  class  of  satellite  necessary  to 
fulfill  military  data  relay  requirements  by  a centralized  network  approach. 
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DEDICATED  DATA  RELAY  SATELLITES:  4 ACTIVE,  1 SPARE 

ON-ORBIT  WEIGHT:  4200  lbs 

ALL  DOWNLINKS  AT  20  GHz 

ALL  CROSSLINKS  AT  60  GHz 

CAPACITY:  20TTC,  12  MRM,  6 HRM 


5 TTC 
3 MRM 

2 HRM 
5 TTC 

3 MRM 
1 HRM 


5 TTC 
3 MRM 

1 HRM 
5 TTC 
3 MRM 

2 HRM 


Fig.  4.5.  A centralized  network  proposed  in  the  SCF  Upgrade  Study  (Ref.  1). 
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4.3  CHARACTERISTICS  OF  CENTRALIZED  NETWORKS 


Of  course  Fig.  4.6  is  just  one  example  of  how  such  a satellite  could  be 
realized,  but  it  serves  to  point  out  some  technical  difficulties  encountered 
in  matching  a centralized  network  approach  to  USAF  requirements  like  the  ones 
in  Table  3.5. 

Such  a satellite  must  have  many  (10  or  more)  independently  steerable 
crosslink  antennas  (or  optical  apertures  m the  case  of  laser  communications). 
The  data  through-put  will  be  in  the  multi-gigabit  per  second  class,  and 
several  such  downlinks  must  be  provided  by  each  data  relay  satellite. 

One  can  say,  independently  of  design  details,  that  such  a satellite  would 
be  large  and  complex  by  today's  standards.  Its  design  would  require  a detailed 
specification  of  user  requirements.  These  requirements  would  then  become 
essentially  frozen  early  in  the  program.  Typical  space  systems  have  a 7 to  10 
year  gestation  period,  and  the  actual  user  requirements  could  change  substan- 
tially before  the  network  became  operational.  These  and  other  considerations, 
summarized  in  Table  4.1,  have  stymied  the  acquisition  of  a space  data  relay 
network  for  military  satellites  in  spite  of  the  obvious  limitations  of  the 
existing  ground-based  network. 

The  next  section  will  explore  an  alternative  approach — a space  data  relay 
network  based  on  a distributed  architecture. 
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TABLE  4.1 


CHARACTERISTICS  OF  CENTRALIZED  SPACE  DATA 
RELAY  NETWORKS 


Topological  Characteristics 

1.  A few  large  nodes 

2.  Many  access  ports  per  node 

3.  Few  alternate  paths 

Programmatic  Characteristics 

1.  Dedicated  data  relay  satellites 

2.  Maximum  network  efficiency,  therefore  lowest 
total  cost 

3.  Large  start-up  costs 

4.  Large  growth/transition  increments 

5.  Unused  capacity  in  orbit 

6.  Keyed  to  a specific  set  of  user  requirements 

7.  Physical  survivability  of  large  data  relay  satellites 
is  an  issue 
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5.  NETWORK  REALIZATION— DISTRIBUTED 

Objections  to  the  centralized  network,  as  applied  to  typical  military 
requirements,  follow  mainly  from  the  size  and  complexity  of  the  data  relay 
satellites.  The  basic  alternatives  are:  reduce  the  requirements  or  divide 
the  data  relay  satellites  into  a number  of  smaller  units.  A step  beyond  this 
second  option  lies  the  type  of  distributed  network  we  will  explore  in  this 
section.  Here  the  functions  of  the  large  data  relay  satellite  will  be  divided 
among  many  small  "nodes",  of  a few  channels  each.  These  nodes  can  be  carried 
as  secondary  payloads  on  user  spacecraft.  Also,  the  clustering  of  MCCs  near 
large  ground  stations  will  be  avoided.  Our  distributed  network  will  permit  the 
MCC's  to  be  widely  distributed  over  the  earth's  surface — even  transportable. 

If  it  proves  feasible,  the  distributed  network  would  have  some  distinct 
advantages  over  centralized  network.  Start-up  costs  would  be  smaller,  growth 
and  transition  more  gradual,  survivability  greater,  and  changes  in  the  user 
requirements  would  have  less  impact  on  network  implementation.  In  this 
section  the  feasibility  of  a distributed  network  is  explored  by  the  method  of 
working  out  a specific  design  example.  This  example  represents  only  one  of 
many  possible  variations  on  the  theme;  nevertheless,  it  serves  to  identify  some 
major  issues  relating  to  the  whole  class  of  distributed  networks.  The  example 
is  based  on  the  network  requirements  used  in  the  last  section  (Table  3.5), 
except  that  these  are  now  considered  to  be  ultimate  goals  toward  which  the 
network  can  gradually  evolve  rather  than  fixed  "requirements"  for  initial 
operation. 

Although  assumptions  and  parameter  values  are  stated  rather  explicitly 
in  this  example,  they  are  quoted  only  for  illustrative  purposes.  They  serve 
to  focus  the  discussion  and  to  help  us  draw  some  general  conclusions,  which 
will  then  not  depend  greatly  on  the  detailed  assumptions. 

The  following  sections  address  topological  and  architectural  issues  only. 
The  underlying  technology  and  hardware  assumptions  and  issues  are  covered  in 
Section  6. 


5.1.  STANDARD  NODES 


The  distributed  network  will  contain  many  small  nodes  carried  on  host 
satellites.  Standardization  and  interoperability  are  therefore  important 
issues.  In  this  example,  therefore,  our  first  step  is  to  hypothesize  a set 
of  "standard  nodes"  to  serve  as  basic  network  building  blocks. 

For  example.  Figure  5.1  shows  three  distinct  types  of  standard  node — one 
for  each  channel  class  (Sec.  3.3).  (Without  going  into  implementation  details, 
which  are  reserved  for  Section  6,  it  appears  that  a different  technology 
would  be  the  choice  for  each  channel  class.)  Nodes  of  the  same  type  are 
interoperable.  Nodes  of  different  types  are  not.  The  nodes  are  intended  to 
be  commensurate  in  size  with  being  a secondary  payload  on  a host  spacecraft. 

In  this  example,  hosts  are  assumed  to  be  in  synchronous  orbit.  However,  the 
concept  applies  as  well  to  Molniya  and  other  high,  non- synchronous  orbits. 

Low  orbits  would  not  be  attractive  locations  for  network  nodes.  The  standard 
nodes  in  Fig.  5.1  are  discussed  in  more  detail  below  and  in  Section  6.3. 

5.1.1.  HRM  NODE 

The  HRM  node  in  Fig.  5.1  provides  one  HRM  access  port  and  relays  that 
1 Gbps  data  stream  to  two  separate  ground  nodes,  arbitrarily  located.  The 
choice  of  one  channel  per  node  for  this  example  is  based  on  physical  size 
considerations  (Sec.  6.3.3),  on  the  fact  that  only  a few  HRM  channels  are 
needed,  and  on  the  fact  that  no  3-Node  space  coverage  is  needed  (Table  3.5). 
(The  latter  would  require  that  some  HRM  nodes  support  two  1 Gbps  crosslinks 
for  cross-orbit  trunking.) 

The  downlink  channels  to  two  separate  ground  sites  meet  the  needs  stated 
in  the  mission  model  (Table  3.1).  (Each  mission  has  two  separate  MCCs.) 
Multiplexing  of  different  1 Gbps  data  streams  is  avoided  on  grounds  that  it  is 
not  necessary  and  is  technically  difficult  (but  not  impossible).  Each  MCC  can 
have  its  own  exit  node  arbitrarily  located.  Large  terminals — in  the  range  of 
60  feet  in  diameter — are  assumed  for  the  HRM  ground  nodes. 
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By  assumption  (Sec.  3.3)  every  channel  includes  a 10  kbps  "forward 
link"  for  spacecraft  commands.  This  capability  is  implicit  in  Fig.  5.1. 
Implementation  is  covered  in  Section  6.2.3. 

5.1.2.  MRM  NODE 

The  MRM  standard  node  contains  3 crosslinks  and  a "multiple  access"  down- 
link, i.e.,  the  downlink  can  talk  to  a number  of  widely  separated  ground  nodes. 
The  crosslinks  are  bi-directional  and  multi-channel.  They  can  support  up  to 
three  MRM  channels  (10  Mbps  each)  in  either  direction.  (As  before,  each  MRM 
channel  has  a 10  kbps  forward  link.)  The  crosslinks  can  serve  either  as  access 
ports  or  as  cross-orbit  trunks  linking  to  other  nodes  in  the  network.  These 
crosslinks  allow  a network  to  grow  in  "tinker-toy"  fashion  as  new  nodes  are 
added  and  crosslinked  together  with  existing  ones. 

The  downlink  can  support  the  equivalent  of  10  MRM  channels  (i.e.,  its 
aggregate  data  rate  is  100  Mbps) . Each  channel  can  be  routed  to  a different 
location,  where  "different"  means  more  than  one  antenna  beamwidth  apart  in  angle. 
Implementation  of  this  type  of  downlink  is  discussed  in  Section  6.2.2.  It  is 
similar  to  one  presently  being  developed  for  mobile/tactical  communications  at 
20  GHz.  MRM  ground  terminals  are  assumed  to  be  smaller  than  HRM  terminals. 

A 40-foot-diameter  antenna  is  used  in  this  example. 

5.1.3.  TTC  NODE 

Since  there  are  many  TTC  users  (30  channels  required),  the  TTC  node  has 
six  crosslinks.  Like  the  MRM  crosslinks,  each  is  bidirectional  and  multi- 
channel. In  this  case  each  can  support  12  TTC  channels  (200  kbps  each)  in 
either  direction  (the  10  kbps  forward  links  is  again  implicit  in  each  channel). 

The  downlink  is  again  multiple  access  like  the  MRM  and  can  support  16 
TTC  channels  (3.2  Mbps)  to  a distributed  set  of  exit  nodes.  The  TTC  ground 
terminals  are  assumed  to  be  in  the  20-foot-diameter  class. 

Again,  these  standard  nodes  reflect  many  arbitrary-but-specif ic  choices 
made  for  illustrative  purposes.  They  are  not  necessarily  optimal  choices. 
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The  following  network  design  example  neglects  the  fact  that  some  or  all  host 
satellites  are  themselves  network  users;  consequently,  fewer  access  ports  will 
be  needed  than  are  shown  in  Table  3.5.  The  availability  and  suitability  of 
host  spacecraft  is  not  touched  on  in  this  study  except  to  say  that  civilian 
communications  satellites  should  be  included  in  the  list  of  possibilities. 

5.2  CONFIGURATION  FLEXIBILITY 

With  this  (or  a similar)  set  of  standard  nodes,  a variety  of  network  con- 
figurations can  be  realized.  Fig.  5.2  shows  some  examples  using  2 and  3 MRM 
nodes  connected  in  different  ways.  Each  configuration  has  a different  capacity, 
space  coverage  and  ground  coverage  (Sec.  3).  This  netting  flexibility  results 
from  the  multi-channel,  bi-directional  capabilities  of  the  crosslinks. 

When  more  than  two  or  three  nodes  are  present,  the  interconnection 
possibilities  are  so  numerous  that  it  helps  to  think  in  terms  of  aggregating 
some  standardized  sub-networks  of  simple  geometry  as  shown  in  Fig.  5.3. 

5.3  EVOLUTIONARY  GROWTH 

One  hoped-for  advantage  of  a distributed  architecture  is  to  realize  a 
graceful  transition  from  the  ground-based  network  to  a space-based  network.  By 
this  we  mean  that  the  space  network  can  grow  in  small  increments  as  programs 
become  operational  or  phase  over  to  its  use.  An  added  advantage  is  that  user 
requirements  could  change  without  seriously  affecting  the  basic  network 
architecture.  They  would  only  affect  how  many  nodes  are  needed  and  in  what 
fashion  they  are  interconnected. 

Assume  for  the  moment  that  the  mission  model  (Table  3.1)  represents  the 
ultimate  far-term  requirement.  Fig.  5.4  shows  how  the  MRM  network  could  evolve 
in  phases  towards  that  end.  It  assumes  that  the  missions  become  operational 
in  sequence  from  top  to  bottom.  Each  mission  has  2 or  3 MCCs  which  are 
separate  and  arbitrarily  located.  The  number  of  channels  required  by  each 
mission  (from  Table  3.4)  is  indicated  next  to  its  MCCs.  Growth  occurs  in 
six  phases — one  for  each  mission  added — as  shown  in  Table  5.1.  For  example, 
phase  1 is  for  mission  S-l  (DSP),  which  requires  5 channels  and  2-Node  space 
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CAPACITY  - 6 CHAN 
SPACE  C0V.-2  NODE 
GND  COV.- OVERLAP 


CAPACITY -4  CHAN 
SPACE  COV. -2  NODE 
GND  COV.  - 2 NODE 


CAPACITY  - 7 CHAN 
SPACE  COV. -3  NODE 
GND  COV.- 2 NODE 


CAPACITY -5  CHAN 
SPACE  COV. -3  NODE 
GND  COV.  - 3 NODE 


CAPACITY - 3 CHAN 
SPACE  COV  - 3 NODE 
GND  COV.  - 3 NODE 
FULLY  REDUNDANT 
DATA  PATHS. 


FiR.  5-2.  Some  examples,  using  2 and  3 MRM  nodes 
bility  provided  by  bi-directional,  multi-channel 


, of  configuration  flexi' 
crosslinks . 


3 


2 


* 14  CHANNELS 


= 14  CHANNELS 


* 15  CHANNELS 


= 13  CHANNELS 


Fig.  5.3.  Larger  networks  can  be  broken  down  into  some  standard  sub- 
network types.  MRM  nodes  are  sir  n.  Numbers  represent  available 
access  ports. 
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FINAL  ACCESS  PORT 
ASSIGNMENTS 


CHANNELS 

REQUIRED 


PHASE  1 


PHASE  2 


PHASE  3 
AND 

PHASE  4 


PHASE  5 


Fig.  5.4.  Example  of  network  growth  assuming  missions  become  opera- 
tial  in  sequence  from  top  to  bottom.  Mission  requirements  from 
Table  3.1  (mission  model).  Node  utilization  at  each  phase  indicated 
in  Table  5.1. 


coverage.  Nodes  1 and  2 are  launched  as  phase  1 and  the  ports  assigned  per 
Table  5.1  (i.e.,  Node  2 has  two  crosslinks  and  4 downlink  channels  in  use). 

The  growth  proceeds  as  shown.  The  final  configuration  of  Fig.  5.4  has  16 
access  ports  available  and  13  assigned.  There  are  many  other  net  configura- 
tions which  could  meet  the  same  requirements. 

The  need  for  multiple-access  downlinks  is  best  pointed  out  by  node  4,  which 
is  linked  to  8 ground  nodes.  As  the  Table  indicates,  its  downlink  data  rate  is 
equivalent  to  5 1/3  channels  (53.3  Mbps).  However,  this  is  an  average  figure; 


TABLE  5.1 

CROSSLINK  AND  DOWNLINK  UTILIZATION  OF  EACH  NODE  FOR  EACH  PHASE  OF  NETWORK 
GROWTH.  THERE  ARE  3 CROSSLINKS  AND  10  DOWNLINK  CHANNELS  AVAILABLE  PER  NODE 


Phase 

Mission 

Added 

Node  number  and  (crosslink/downlink) 

1 2 3 4 5 

loading) 

6 

1 

Add  S-l 

3/6 

2/4 

— 

- 

— 

— 

2 

Add  S-3 

3/6 

2/4 

3/6 

- 

— 

— 

3 

Add  M-l 

3/6 

2/4 

3/6 

1/3 

- 

— 

4 

Add  0-3 

3/6 

2/4 

3/6 

2/4 

— 

— 

5 

Change  0-3 

3/6 

2/4 

3/6 

2/4 

2/1 

1/0 

5 

Add  S-5 

3/6 

2/4 

3/6 

2-/4— 

2 3 

2-/2— 

3 3 

l-j/0 

6 

Add  S-7 

3/6 

2/4 

3/6 

2-/5^ 
j ^3 

2 2 
2-/3- 
3'  3 

lf/0 
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the  peak  data  rate  can  be  80  Mbps.  This  is  why  a nominal  capability  of  10 
channels  (100  Mbps)  was  chosen  for  the  MRM  standard  node  downlink. 

5.4  NETWORK  ORGANIZATION 

Figure  5.5  provides  an  illustration  of  some  different  possibilities  for 
network  organization  and  control  opened  up  by  the  distributed  architecture. 

If  organized  as  a "shared  network"  (Sec.  2.6),  the  entire  network  could  be 
under  central  control  like  the  SCF.  The  user  MCCs  would  request  and  be  pro- 
vided channels  via  an  order  wire  (not  shown)  to  a network  control  ground  node 
(also  not  shown).  This  control  node  would  have  to  be  capable  of  communicating 
with  every  other  network  node  (both  ground  and  space  nodes).  There  should  be 
redundant  control  nodes  to  retain  the  survivability  advantage  of  the  distributed 
network. 

Another  possibility  is  to  divide  the  network  into  sub-networks  for  control 
purposes.  In  Fig.  5.5  missions  S-l  and  S-3  could  each  have  its  own  "mission- 
specific"  network.  The  network  resources  (nodes  1,  2 and  3)  could  be  "detached" 
to  the  operational  control  of  the  using  missions  in  this  case.  As  shown,  the 
remaining  missions  are  sharing  a common  network  under  a central  control.  With 
either  type  of  organization,  alternate  paths  are  available  to  every  mission 
since  all  nodes  are  interoperable  and  have  the  built-in  flexibility  to  permit 
reconfiguring  the  network  in  orbit. 

5.5  CENTRALIZED/DISTRIBUTED  COMPARISON 

The  MRM  standard  node  was  used  to  illustrate  the  examples  just  presented. 
Similar  ideas  apply  to  the  TTC  and  HRM  nodes.  The  characteristics  of  a network 
architecture  based  on  the  distributed  approach  are  summarized  in  Table  5.2.  A 
comparison  of  the  features  of  centralized  and  distributed  architectures  is 
given  in  Table  5.3.  The  underlying  technical  issues  and  assumptions  are 
covered  in  the  Section  6. 
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TABLE  5.2 

CHARACTERISTICS  OF  THE  DISTRIBUTED  NETWORK 


[ 


f 


Topological  Characteristics 

• Many  Smaller  Nodes 

• Fewer  Access  Ports  Per  Node 

• More  Trunk  Links  Required 

• Lower  Capacity  Nodes  and  Trunks 

• More  Alternate  Paths 

Programmatic  Characteristics 

• Larger  Total  Investment  Than  Centralized  Approach 
(To  Meet  Same  Requirement) 

• Smaller  Initial  Investment 

• Smaller  Growth  Increments  (Phased  Changes) 

• Network  Matched  to  Actual  Requirements  (vs  Predicted  Requirements) 

• Technology  Not  Frozen 

• Network  Nodes  can  be  Dedicated  Satellites  or  Packages 
On  Host  Vehicles 

• Flexible  Network  Organization  (Multi-Mission  or  Mission-Specific) 

• Survivability  Through  Dispersal  of  Nodes  in  Space  and  on  Ground 
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6.  TECHNOLOGY  ISSUES  AND  ASSUMPTIONS 

The  previous  sections  dealt  with  topological  and  architectural  issues. 
Little  was  said  of  technical  considerations,  although  they  were  implicit 
throughout  the  discussions.  The  purposes  of  this-  section  are  to  make  explicit 
those  underlying  technical  assumptions  and  point  out  some  of  the  issues  raised. 

The  method  used  is  to  give  specific  examples  of  one  way  the  various  items 
could  be  realized.  No  attempt  is  made  to  consider  all  the  ways  or  to  select 
the  optimur  one.  That  would  be  far  beyond  the  scope  of  this  report.  The 
parameter  values  are  sometimes  detailed  and  explicit  for  reasons  of  self- 
consistency.  Again,  these  are  intended  as  being  illustrative  and  not  as  firm 
technical  proposals. 

6.1  CROSSLINKS 

There  are  two  types  of  crosslinks:  access  links  (MSC  to  network)  and 
cross-orbit  trunks  (within  network).  Data  rates  range  from  around  200  kbps  to 
around  1 Gbps.  The  driving  consideration  for  any  of  these  applications  is  to 
minimize  aperture  size  and  package  weight.  Implicit  in  the  foregoing  discus- 
sions was  the  assumption  that  each  "access  port"  represents  an  independently 
steered,  narrow  beam  crosslink  covering  a wide  angular  field.  In  the  central- 
ized network,  the  object  was  to  pack  many  such  "ports"  onto  a few  data  relay 
satellites  (nodes).  The  distributed  approach  strove  for  small  nodes  of  a few 
ports  each,  suitable  as  secondary  payloads  on  host  spacecraft.  In  either 
approach  the  user  MSC  must  not  be  overburdened  by  its  network  interface  package. 
All  of  these  considerations  place  a high  penalty  on  crosslink  size  and  weight. 

6.1.1  MILLIMETER  WAVE  AND  OPTICAL  TECHNOLOGIES 

Figure  6.1  indicates  the  range  of  package  weights  achieveable  (by  current 
estimates)  with  optical  or  60  GHz  crosslink  frequencies.  The  60  GHz  weight 
begins  to  increase  rapidly  above  10  Mbps  as  the  RF  power  requirement  escalates. 
Optical  system  weights  are  more  affected  by  overhead  items  (pointing  and 
tracking,  stable  platforms,  etc.)  and  are  less  sensitive  to  data  rate. 
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Based  on  weight  alone,  there  is  no  clear  preference  for  optics  over  RF 
except  at  data  rates  of  a few  hundred  megabits/sec  and  above.  Aperture 
diameter  comparisons  (Fig.  6.2)  however  make  optics  appear  more  attractive 
over  the  entire  data  rate  range,  but  especially  so  at  10  Mbps  and  above. 

This  study  therefore  assumes  an  optical  implementation  for  the  crosslinks 
in  the  MRM  (10  to  30  Mbps)  and  HRM  (~  1 Gbps)  data  rate  regimes.  An  RF  rather 
than  optical  implementation  is  considered  to  be  an  appropriate  choice  for  TTC 
(~  200  kbps)  in  spite  of  the  larger  aperture  diameter.  The  TTC  channels  pro- 
vide spacecraft  control  functions  (Fig.  2.1)  and  it  is  recognized  that  some 
form  of  ommi-directional , low  data  rate  capability  is  needed  for  launch 
operations,  attitude  acquisition,  and  anomaly  recovery  situations.  This 
capability  is  more  easily  realized  at  RF  than  at  optical  frequencies.  The 
frequency  of  60  GHz  is  chosen  for  this  study  because,  due  to  oxygen  absorption, 
the  atmosphere  would  be  opaque  to  ground-based  jammers  (~  100  dB  attenuation). 

6.1.2  60  GHZ  CROSSLINKS 

Figure  6.3  provides  an  indication  of  the  hardware  required  to  realize  a 
60  GHz  crosslink  in  the  TTC  data  rate  regime.  On  the  left  is  a MSC  interface 
package  sending  200  kbps  and  receiving  10  kbps  (spacecraft  commands).  It  has 
an  18  in.  steerable  dish,  a 2W  RF  amplifier,  and  a weight  and  power  of  90  lb 
and  55  watts.  The  right-hand  package  would  be  on  a node  of  the  distributed 
network.  It  could  serve  as  an  access  port,  (receiving  200  kbps  and  sending 
10  kbps  to  MSC)  or  as  a cross-orbit  trunk  linking  up  to  12  TTC  channels  in 
either  direction  (2.4  Mbps)  to  another  network  node.  (All  channels  include  a 
10  kbps  capability  in  the  "forward"  direction  MCC  to  MSC  (Section  3.3).)  An 
equivalent  package  for  the  centralized  architecture  (Fig.  4.4)  would  serve 
only 'as  an  access  port  and  would  be  slightly  less  in  weight  because  of  the 
smaller  transmitter  required  (10  kbps  only). 

A typical  link  budget  is  given  in  Table  6.1  and  4 weight/power  budget  in 
Table  6.2.  All  weights  and  power  numbers  are  rough  estimates. 


Fig.  6.2.  Typical  crosslink  aperture  diameters  for  optical  and  60  GHz 
technologies.  For  different  receive  and  transmit  apertures,  /DrDt  must 
fall  on  curve 
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TABLE  6.1 

LINK  BUDGET  FOR  60  GHZ  TTC  ACCESS  LINK 


Trans.  RF  Power  (2W  irapatt) 

3.0 

dBW 

Trans.  Ant.  Gain  (18  in,  55%  eff.) 

46.0 

dBI 

Path  Loss  (/3  Rsynch) 

-224.7 

dB 

Rec.  Ant.  Gain.  (3  ft,  55%  eff.) 

52.5 

dBI 

Rec.  Signal  Pover 

-123.2 

dBW 

Df ! t Rate  (200  kbps) 

- 53.0 

dB-Hz 

Sys.  Noise  (2000°K) 

+195.6 

dBW/ Hz 

E,  /N  available 
bo 

+ 19.4 

dB 

E./N  required  (~  10  BER) 
b o 

10.0 

dB 

Misc.  losses  and  margin 

9.4 

dB 

TABLE  6.2 

60  GHZ  CROSSLINK  WEIGHT  AND  DC  POWER  ESTIMATES 

Item  MSC  Pkg  Network  Node  Pkg 


Mod  + R 

X j 

38  lb 

26W 

38  lb 

26W 

* 

Impatt  PA 

14  lb 

15W 

22  lb 

30W 

Antenna  + Point 

38  lb 

14W 

55  lb 

19W 

Total  Wt . /Pwr. 

90  lb 

55W 

115  lb 

75W 

One  hot,  one  cold  spare  for  MSC  package.  Two  hot,  one  cold  spare  for  Network 
Package. 

Version  for  centralized  architecture  would  have  a < 1 W PA  (forward  data 
rate  = 10  kbps).  Package  Wt./Pwr.  ~ 100  lb,  60  W. 
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6.1.3  LASER  DIODE  CROSSLINKS 


The  Medium  Rate  Mission  (MRM)  data  rates  appear  to  be  compatible  with 
emerging  CW  laser  diode  technology  in  the  0.85  micron  wavelength  range.  This 
is  being  vigorously  pursued  by  the  commercial  sector  in  connection  with  optical 
fiber  telephone  trunks.  One  attractive  prospect  offered  by  this  technology  is 
the  possibility  of  optical  heterodyne  receivers  rather  than  the  direct-detection 
receivers  heretofore  used  in  optical  links  of  less  than  10  micron  wavelength. 

The  theoretical  advantage  of  heterodyne  detection  in  terms  of  a higher 
data  rate  per  milliwatt  of  available  laser  power,  is  illustrated  by  Fig.  6.4. 

The  approximately  10  dB  advantage  enjoyed  by  heterodyne  systems  arises  mainly 
from  the  type  of  optical  detector  used.  Direct  detection  systems  require 
detectors  with  internal  gain,  such  as  avalanche  photodiodes,  which  have  excess 
noise.  In  a heterodyne  receiver  (Fig.  6.5),  gain  is  provided  by  the  local 
oscillator  laser  rather  than  the  photodetector,  and  quantum-limited  performance 
should  be  attainable  with  silicon  PIN  diode  detectors. 

Realizing  this  advantage,  however,  requires  significant  technical  develop- 
ments in  the  areas  of  stable  lasers  and  narrow-beam  pointing  and  tracking. 
Although  far  from  maturity,  this  heterodyne  technology  appears  feasible  and 
is  therefore  adopted  to  Illustrate  this  study.  Figure  6.6  shows  an  MRM  optical 
crosslink  with  a 10  milliwatt  (-20  dBW)_ laser  diode,  and  10  cm  (4  inch)  optics 
which,  according  to  Fig.  6.4,  should  achieve  data  rates  in  the  10  to  30  Mbps 
class  with  a CW  laser  power  of  10  milliwatts,  which  is  easily  available  today. 
Higher  power  diodes  (which  are  now  coming  available  commercially)  or  larger 
optics  could  extend  the  achievable  data  rate  to  the  gigabit  per  sec  range. 

At  this  level  of  detail  we  cannot  distinguish  between  the  weight  and 
power  estimates  for  a 10  Mbps  package  and  a 30  Mbps  package.  Both  would  be  in 
the  100  lb;  100  W class.  The  10  Mbps  version  would  be  a MSC  interface  package 
or  an  access  port  of  the  centralized  architecture.  The  30  Mbps  version  per- 
tains to  the  MRM  standard  node  (Fig.  5.1)  of  the  distributed  architecture. 
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Fig.  6.4.  Data  rate  vs  laser  transmitter  output  power  for  direct 
detection,  heterodyne  and  homodyne  detection  techniques. 


RANGE:  -fZ  R#ync  (73  x ICTkrn) 

MAX  DATA  RATE:  30Mbps,  BI-DIRECTIONAL 


6.1.4  Nd : YAG  LASER  CROSSLINKS 


The  development  of  direct  detection  optical  crosslinks  using  Nd:YAG  lasers 
is  already  well  advanced.  That  work  has  primarily  addressed  higher  data  rate 
applications  (100  Mbps  to  1 Gbps),  but  could  be  applied  to  lower  data  rates  as 
well.  For  the  purpose  of  this  study  we  have  assumed  this  type  of  link  for  the 
HRM  (1  Gbps)  class  of  service.  Some  typical  parameters  of  such  a link  are 
shown  in  Fig.  6.7.  As  mentioned  in  the  last  section,  it  is  possible  that 
heterodyne  diode  laser  technology  could  eventually  be  applied  to  the  HRM  as 
well  as  the  MRM  channels;  however,  that  is  not  assumed  in  this  study. 

6.2  UPLINKS  AND  DOWNLINKS 

Both  centralized  and  distributed  architectures  need  multi-channel  trunks 
from  the  space  nodes  to  the  ground  nodes.  By  assumption,  all  channels  have  a 
10  kbps  forward  direction  capability;  therefore,  only  a modest  uplink  data  rate 
is  needed. 

This  study  assumes  that  all  downlinks  are  at  20  GHz.  This  is  a presently 
unoccupied  band  and  requires  smaller  satellite  antennas  than  the  SHF  band. 
Uplinks  are  assumed  to  be  at  44  GHz.  Because  the  data  rates  are  low  and 
terminal  sizes  relatively  large  (20  to  60  feet),  jam  resistance  is  inherently 
high  and  only  a minimal  amount  of  band-spreading  would  be  sufficient  protection 
against  any  plausible  threat. 

6.2.1  DOWNLINKS  FOR  THE  CENTRALIZED  NETWORK 

The  centralized  architectures  (Figs.  4.4  and  4.5)  assume  five  large 
ground  stations  (exit  nodes)  uniformly  distributed  around  CONUS.  A particular 
mission  may  have  MCCs  situated  at  more  than  one  exit  node.  In  Fig.  4.4  the 
simplifying  assumption  was  made  that  all  channels  are  downlinked  to  all  exit 
nodes.  This  means  that  all  channel  switching  operations  can  be  done  on  the 
ground.  Figure  6.8  indicates  the  downlink  hardware  required  to  do  this  for 
Node  2 of  Fig.  4.4.  (Some  of  the  indicated  channels  arrive  by  crosslink  from 
Node  3.)  The  link  budget  is  given  in  Table  6.3.  It  assumes  a 60  foot,  580°K 
terminal.  The  technique  of  generating  five  beams  by  five  fixed  feeds  of  a 
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BASEBAND  MODULATOR  POWER  AMPS  MULTIBEAM 
MULTIPLEXER  ANTENNA 

5 FIXED  BEAMS 
1°  BEAMWIDTH 


Fig.  6.8.  20  GHz  downlink  concept  for  centralized  architecture  (Node  2, 
Fig.  4.4).  No  on-board  Channel  routing.  All  5 ground  nodes  receive  all 
channels . 


multi-beam  antenna  requires  the  satellite  to  remain  fixed  relative  to  the  five 
ground  stations.  A more  flexible  approach  would  be  desired  in  an  operational 
system.  Also,  some  savings  in  RF  power  (about  3 dB)  could  be  realized  by  on- 
board channel  switching.  With  this,  channels  would  be  routed  only  to  desired 
ground  stations  rather  than  all  stations.  These  issues  were  not  resolved 
within  the  scope  of  this  study  as  they  do  not  affect  architectural  conclusions. 


TABLE  6.3 

20  GHZ  DOWNLINK  BUDGET  FOR  CENTRALIZED  NETWORK 


RF  Power  per  channel  (10W  per  beam) 

10 

dBW 

Antenna  gain  (1°  beam,  43  in,  55%  eff.) 

44 

dBI 

Satellite  EIRP 

54 

dBW 

Path  loss  (Rsynch) 

-211 

dB 

Rec.  Ant.  Gain  (60  ft,  55%  eff.) 

69 

dBI 

Rec.  Signal  Power 

- 88 

dBW 

Data  Rate  (2  Gbps) 

- 93 

dB-Hz 

System  Noise  (580°K) 

+201 

dBW/ Hz 

E,  /N  available 

D O 

20 

dB 

E, /N  required 

D O 

-10 

dB 

Margin  plus  misc.  losses 

10 

dB 
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6.2.2  DOWNLINKS  FOR  THE  DISTRIBUTED  NETWORK 


It  was  thought  desirable  for  this  study  to  relax  the  constraint  of  having 
a few  large  ground  nodes  with  clustered  MCCs  and  allow  MCCs  to  be  arbitrarily 
located  instead.  (As  we  will  see  the  technical  impact  of  this  is  acceptable.) 

A totally  distributed  ground  segment  was  therefore  adopted  as  a feature  of  the 
distributed  architecture  (Section  5).  (A  distributed  ground  segment  in  con- 
junction with  a centralized  space  segment  is  also  possible,  but  was  not 
considered. ) 

The  basic  assumptions  governing  downlink  structure  for  the  distributed 
network  are: 

1)  The  MCC  locations  are  arbitrary 

2)  Each  MCC  is  an  exit  node  of  the  network  (as  opposed  to  a few 
large  exit  nodes  with  clustered  MCCs). 

3)  Each  mission  can  have  several  MCCs,  therefore. 

4)  Network  channels  must  have  a point-to-multipoint  capability  (Fig.  2.5). 

5)  MCCs  of  the  same  mission  are  separated  by  more  than  one  beam- 
width  of  the  downlink  antenna. 

Under  these  assumptions,  on-board  channel  routing  is  a necessity  for  the 
distributed  architecture.  An  earth  coverage  broadcast  mode  could  eliminate 
the  need  for  switching,  but  is  not  feasible  because  of  RF  power  requirements. 

The  function  of  the  downlink  routing  processor  is  then  illustrated  by  Fig.  6.9, 
which  shows  two  channels  being  distributed  among  five  separate  MCCs  (two  for 
mission  A,  3 for  mission  B).  One  way  to  realize  this  function  is  by  means  of 
time-division  multiplexing  (TDM)  with  a hopped-beam  antenna. 

This  technique  is  best  visualized  with  the  aid  of  Fig.  6.10.  (The 
particular  parameter  values  apply  to  the  MRM  standard  node,  Section  6.3.2). 

Here  the  input  channels  (from  the  same  node  or  from  other  nodes  via  cross- 
orbit trunks)  are  stored  in  a buffer  memory,  then  time-division-multiplexed 
onto  an  RF  carrier  at  a higher  data  rate  by  the  digital  commutator.  An  RF 
switch,  synchronized  with  the  commutator,  connects  the  RF  carrier  to  the 
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appropriate  antenna  feed.  Each  antenna  feed  represents  a spatially  distinct 
downlink  beam. 

For  example,  the  MRM  downlink  of  Fig.  6.10  has  a capacity  of  10  10  Mbps 
channels  (some  of  which  may  carry  the  same  data,  but  to  separate  locations). 

If  a MCC  located  in  beam  3 is  receiving  one  channel,  the  RF  switch  will  dwell 
on  port  3 for  10  percent  of  the  time.  The  burst  data  rate  into  port  3 is 
100  Mbps.  The  average  data  rate  is  10  Mbps,  or  one  channel. 

There  is  a tradeoff  between  beamwidth,  number  of  beams  (a  measure  of 
complexity)  and  RF  power.  Figure  6.11  shows  the  geometrical  relationship 
between  beamwidth  and  number  of  beams.  The  37  and  61  beam  geometries  were 
chosen  for  the  TTC  and  MRM  standard  nodes  respectively  (see  Sections  6.3.1 
and  6.3.2).  Typical  downlink  parameter  values  are  shown  in  Table  6.4.  Note 
that  particular  terminal  sizes  are  assumed.  (We  will  return  to  the  HRM 
downlink  shortly.) 

Perhaps  a better  way  to  implement  the  TDM  time-hopped-beam  technique  is 
shown  in  Fig.  6.12.  It  is  conceptually  identical  to  Fig.  6.10  except  that  it 
uses  a phased-array  antenna  with  distributed,  solid-state  power  amplifiers 
rather  than  a single  large  PA  (which  would  probably  be  a TWTA).  Such  an  array 
antenna  (Fig.  6.13)  is  presently  being  developed  at  Lincoln  Laboratory  for  the 
USAF  Space  Division  as  part  of  the  Advanced  Space  Communications  Program  for 
mobile/tactical  terminals. 

While  the  TTC  and  MRM  downlinks  employ  the  beam-hopping  technique,  this 
study  assumes  the  HRM  nodes  do  not.  The  reasons  are:  first,  at  a 1 Gbps  input 
data  rate  TDM  would  be  difficult  to  implement  and  second,  only  two  downlink 
channels  per  node  are  necessary  for  HRM  according  to  the  mission  model  used 
here.  A simple  scheme  using  two  independently  steered  dishes  is  therefore 
described  in  Section  6.3.3. 
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Fig.  6.12.  Time-hopped -beam  downlink  using  array  antenna  with  distributed 
power  amplifiers. 
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Fig.  6.13.  Hopped-beam  TDM  downlink  antenna  under  development  at 
Lincoln  Laboratory. 
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TABLE  6.4 

TECHNOLOGY  ASSUMPTIONS  FOR  THE  20  GHZ  DOWNLINKS 
THE  DISTRIBUTED  NETWORK  ARCHITECTURE 


6.2.3  UPLINK  JAMMING 


The  10  kbps  forward  links  on  each  channel  type  are  used  for  MSC  commands 
and  for  a network  control  orderwire.  The  only  issue  is  how  to  protect  them 
against  uplink  jamming.  Table  6.5  shows  the  link  budget  for  a 250W,  60  ft 
ground  terminal  transmitting  to  an  earth  coverage  horn  on  the  satellite,  at  a 
44  GHz  uplink  frequency.  Table  6.6  shows  the  levels  of  jammer  EIRP  that  can 
be  withstood  by  each  terminal  with  no  band-spreading.  Band  spreading  of 
100  MHz  could  provide  an  additional  40  dB  of  AJ  protection.  In  short,  the 
network  jplinks  can  be  protected  against  any  plausible  jamming  threat.  Uplink 
multiple  access  could  be  implemented  by  frequency  division  multiplexing  (FDM) 
techniques. 

6.3  STANDARD  NODE  DESCRIPTIONS 

The  concept  of  "standard  nodes"  was  introducted  and  used  in  Section  5 with 
little  in  the  way  of  supporting  physical  descriptions.  This  section  provides 
brief  descriptions  of  the  technical  assumptions  implicit  in  the  distributed 
architecture  discussions. 

6.3.1  TTC  STANDARD  NODE  (~  200  kbps  SERVICE) 

An  example  of  TTC  standard  node  Implementation  is  shown  in  Fig.  6.14  with 
parameter  assumptions  listed  below. 

Cross  Links  (Sec.  6.1.2) 

Frequency:  60  GHz 
Number:  6 

Functions:  (a)  TTC  access  port,  200  kbps  return,  10  kbps  forward 

(b)  TTC  cross-orbit  trunk,  up  to  12  TTC  channels  (2.4 
Mbps)  either  direction 

Power  Amplifier:  3 impatt  diode  amplifiers  of  2W  each,  2 hot,  1 
cold  spare 

RF  Power:  4 W 
Downlink:  (Sec.  6.2.2) 

Frequency:  20  GHz 

Type:  beam-hopped,  TDM 

Capacity:  16  TTC  channels  (3.2  Mbps) 
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TABLE  6.5 

44  GHZ  UPLINK  BUDGET  (NO  SPREADING) 


1. 

Power  Transmitted  (250W) 

24 

dBW 

2. 

Trans.  Ant.  Gain  (60  ft) 

73 

dBI 

3. 

Ground  term.  EIRP 

97 

dBW 

4. 

Path  Loss 

-218 

dB 

5. 

Rec.  Ant.  Gain  (Earth  Cov.) 

20 

dBI 

6. 

Rec.  Sig.  Pwr. 

-101 

dBW 

7. 

Data  Rate  Per  Chan  (10  kbps) 

- 40 

dB-Hz 

8. 

System  Noise  (1800°K) 

+196 

dBW/ Hz 

9. 

E /N  Available 
b o 

55 

dB 

10. 

E, /N  Required 
bo 

- 10 

dB 

11. 

Margin  + Loss  Allowance 

- 10 

dB 

12. 

Excess  Margin 

35 

dB 

13. 

Jammer  EIRP  Required  (item  3 + 12) 

132 

dBW 

TABLE  6.6 

44  GHZ,  10  KBPS  UPLINK  ANTIJAM  CAPABILITY  (NO  SPREADING) 


Channel  Type 

HRM 

MRM 

TTC 

Uplink  Data  Rate  Per  Channel 

10  kbps 

10  kbps 

10  kbp 

Terminal  Size  (ft) 

60  ft 

40  ft 

20  ft 

Antenna  Gain  (dBI) 

73 

73 

67 

RF  Power  (dBW) 

250 

250 

250 

Terminal  EIRP  (dBW) 

97 

97 

91 

Excess  Margin 

35 

35 

29 

Equivalent  Jammer  EIRP  (dBW) 

132 

132 

120 
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Antenna:  32  Element  phased  array,  - 12  In.  diameter 
Hepped  beamwidth:  3.6° 

Operating  field  of  view:  earth  coverage 
Ground  Terminal:  20  ft,  580°K 
Uplink:  (Sec.  6.2.3) 

Frequency:  44  GHz 

Type:  Earth  coverage,  frequency  division  multiple  access 

Capacity:  16  TTC  "forward"  channels  (160  kbps) 

Terminal:  20  ft,  250W 

Spread  bandwidth:  < 100  MHz 

The  routing  processor  would  handle  both  the  downlink  routing  (Section 
6.2.2)  and  crosslink  routing.  A control  orderwire  to  the  processor  from  a 
network  controller  on  the  ground  is  implied. 

The  TTC  standard  node,  as  it  is  described  above,  is  not  particularly 
plausible  as  a secondary  payload.  The  six  individually  steered  3 ft  antennas 
would  probably  dominate  the  host  vehicle  design.  Other  TTC  package  configu- 
rations should  be  explored.  One  option  is  to  reduce  the  number  of  crosslinks 
from  six  to  three  per  node,  in  which  case  it  would  take  more  than  twice  as 
many  standard  nodes  to  meet  an  equivalent  network  requirement.  Another  option 
would  be  to  develop  a 60  GHz  version  of  the  multiple-access  antenna  concept 
used  in  TDRSS  (See  Section  6.4).  This  would  allow  several  access  links  to 
share  the  same  physical  aperture.  Still  another  option  would  be  to  use  optical 
crosslinks  for  TTC,  but  some  form  of  RF  link  (perhaps  at  S-band)  with  an 
ommi-directional  antenna  on  the  MSC  would  still  be  required  for  initial 
acquisition  or  emergency  operations. 

Finally,  one  should  consider  architectures  in  which  the  ground-based 
network  carries  the  bulk  of  low-priority,  TTC-only  traffic  while  a distributed 
space  data  relay  network  serves  high  priority  TTC  users  along  with  HKM  and 
MRM  users. 


6.3.2  MRM  STANDARD  NODE  (~  10  MBPS  SERVICE) 

The  example  configuration  is  shown  in  Fig.  6.15.  Assumed  parameters  are 
summarized  below: 

Optical  Cross  Links  (Sec.  6.1.3) 

Wavelength:  ~ 0.85  microns 
Laser:  GaAs  diode 
Optical  Power:  ~ 10  mW 
Number  of  crosslinks  per  node:  3 

Function:  (a)  MRM  access  port,  10  Mbps  return,  10  kbps  forward 

(b)  MRM  cross-orbit  trunk,  up  to  3 MRM  channels  (30 
Mbps)  either  direction 

Downlink  (Section  6.2.2) 

Frequency:  20  GHz 

Type:  beam-hopped,  time-division  multiplexed 
Capacity:  10  MRM  channels  (100  Mbps) 

Antenna:  64  element  phased  array,  - 22  in.  diameter 
Hopped  beamwidth:  2° 

Operating  field  of  view:  earth  coverage 
Ground  Terminal:  40  ft,  580°K 

Uplink: 

Essentially  same  as  TTC  standard  node 

6.3.3  HRM  STANDARD  NODE  (~  1 GBPS  SERVICE) 

Figure  6.16  shows  the  node  configuration.  It  provides  a single  HRM 
channel  and  can  relay  it  to  two  ground  sites  via  two  individually  steered  30 
inch  antennas.  The  beam-hopped  TDM  technique  was  not  considered  necessary 
in  this  case,  considering  that  implementation  at  1 Gbps  would  be  difficult. 
The  parameter  assumptions  are: 

Optical  Crosslink  (Sec.  6.1.4) 

Wavelength:  0.54  microns 
Laser:  Nd:YAG,  doubled 
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Number  per  Node:  1 
Function:  HRM  access  port 

Downlink 

Frequency:  20  GHz 

Antennas:  2,  30  in.  independently  steered 
Capacity:  1 HRM  Channel  (1  Gbps)  per  beam 
Ground  Terminal:  60  ft,  580°K 
Uplink: 

Essentially  same  as  TTC  standard  node 
6.4  MULTIPLE  ACCESS  ANTENNAS 

A problem  noted  above  with  the  TTC  standard  node  was  the  number  of 
separate  apertures  needed.  The  TDR  Satellite  avoids  a similar  problem  by  its 
Multiple  Access  Antenna  (Fig.  4.2),  for  which  up  to  20  access  links  share  the 
same  physical  aperture.  There  is  a technical  problem  in  applying  this  concept 
at  60  GHz.  The  NASA  antenna  is  a 30  element  phased  array  at  2.3  GHz.  To 
maintain  roughly  the  same  gain  and  angular  coverage  at  60  GHz  would  imply  a 
20,000  element  antenna.  (The  number  of  elements  scales  as  the  frequency 
squared.)  A more  accurate  estimate  (Table  6.7)  Indicates  that  4000  elements 
is  about  the  right  number.  An  equivalent  multiple  beam  implementation  of  this 
antenna  would  require  4000  feed  horns.  Antennas  in  this  class,  that  are  suit- 
able for  satellite  applications,  do  not  presently  exist. 


TABLE  6.7 

A 60  GHZ  EQUIVALENT  TO  THE  TDRSS  S-BAND  MULTIPLE  ACCESS  ANTENNA 


1. 

Frequency 

60 

GHz 

2. 

Wavelength 

0.5 

cm 

3. 

Angular  coverage  (same  as  TDRSS,  orbits 

below  2000  NM) 

28' 

> 

4. 

Element  gain  (determined  from  item  3) 

17 

dBI 

5. 

Antenna  array  gain  (from  link  budget 

Table  6.1) 

53 

dBI 

6. 

7. 

2 

Array  total  diameter  (A  = X G/4tt) 

Number  of  elements  (10  log  N ■=  item  5-item  4) 

- 70 

~ 4000 

cm 
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GLOSSARY  OF  ACRONYMS  AND  ABBREVIATIONS 


AJ  Anti-jam 

AFSC  US  Air  Force  Systems  Command 

ASAT  Antisatellite 

3 

C Command,  Control  and  Communications 

3 

C I Command,  Control,  Communications  and  Intelligence 

CMD  Command 

CONUS  Continental  United  States 

CW  Continuous  Wave 

DSP  Defense  Support  Program 

DC  Direct  Current 

FDM  Frequency  Division  Multiplexing 

HRM  High  Rate  Mission  Data 

IF  Intermediate  Frequency 

MA  Multiple  Access 

MCC  Mission  Control  Center 

MRM  Medium  Rate  Mission  Data 

MSC  Mission  Spacecraft 

NASA  National  Aeronautics  and  Space  Administration 

PA  Power  Amplifier 

PIN  Positive-Intrinsic-Negative 

PLL  Phase  Locked  Loop 

RF  Radio  Frequency 

RTS  Remote  Tracking  Station 

SD  Space  Division  of  AFSC 

SCF  Satellite  Control  Facility 

SCS  Satellite  Control  Satellite 

SPADOC  Space  Defense  Operations  Canter 

STC  Satellite  Test  Center 

STDN  Space  Flight  Tracking  and  Data  Network 
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GLOSSARY  OF  ACRONYMS  AND  ABBREVIATIONS  (Cont.) 


TDM 

TDRSS 

TTC 

USAF 


Time  Division  Multiplexing 
Tracking  and  Data  Relay  Satellite  System 
Tracking,  Telemetry  and  Command 
United  States  Air  Force 
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Today  military  satellites  are  controlled  through  a worldwide  network  of  ground-based  tracking  stations. 

A space  data  relay  network,  similar  to  NASA's  Tracking  and  Data  Relay  Satellite  System  (TDRSS),  could 
have  substantially  greater  coverage,  data  througiput  and  survivability  However,  stated  military  require- 
ments demand  large  and  complex  data  relay  satellite  designs.  The  high  cost  and  technical  risk  have  therefore 
inhibited  the  development  of  a military  apace  data  relay  network.  An  alternative  space  data  relay  network 
architecture  i.t  introduced  in  this  report.  It  distributes  network  assets  among  the  user  spacecraft  rather 
than  centralizing  them  in  the  form  of  large  data  relay  satellites.  The  expected  requirements  are  reviewed 
and  two  system  design  examples  are  presented  to  illustrate  the  essential  differences  between  the  centralized 
and  distributed  architectures  Also  discussed  are  die  technologies  needed  to  implement  a distributed  network, 
which  include  advances  in  laser  communications,  millimeter  wave  techniques  and  on-board  signal  processing. 
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